Distributed multi-user mashup

ABSTRACT

A mashup session manager maintains state of the mashup session to ensure presentation consistency/uniformity across the execution environments. The mashup session manager also tracks the participating execution environments associated with a mashup session (e.g., usernames, device identifiers, network addresses, etc.), and transmits data for presentation consistency to the participating execution environments. In some cases, a view of the mashup session at a participating execution environment may not be current (“stale mashup session view”). The mashup session manager can detect if a view at a participating execution environment is of a past mashup session state, and provide data for the stale mashup session view to become current. In addition, the mashup session manager can propagate design modifications to the participants of the mashup session.

RELATED APPLICATIONS

This application is a continuation application that claims the benefitof U.S. patent application Ser. No. 12/651,072 filed Dec. 31, 2009.

BACKGROUND

Embodiments of the inventive subject matter generally relate to thefield of mashup applications, and, more particularly, to a multi-usermashup session.

A mashup application (“mashup”) is constructed with reference to two ormore distinct services. The services referenced by a mashup return datain response to a request that can indicate one or more parameters. Aservice may be a data service or a functional service. The references tothe services are wired together to meet a situational or niche needcontemplated by a designer of the mashup. The mashup itself can beimplemented with logic to operate upon the data returned from one ormore of the services. The mashup then presents an output resulting fromthe returned data.

SUMMARY

Embodiments include a method for presenting a multi-user mashup sessionacross execution environments. The method generates a mashup sessionidentifier for a mashup session based, at least in part on a mashup. Aplurality of participant devices is associated with the mashup sessionidentifier, and connections are established with the plurality ofparticipant devices. The state data is maintained for the mashup sessionthat correspond to a current view of the mashup session after a mostrecent action performed on the mashup during the mashup session at afirst of the plurality of participant devices. An indication of thestate data is communicated among the plurality of participant devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The present embodiments may be better understood, and numerous objects,features, and advantages made apparent to those skilled in the art byreferencing the accompanying drawings.

FIGS. 1A and 1B depict conceptual diagrams of consistent views of acurrent state of a mashup session across multiple executionenvironments. FIG. 1A depicts a conceptual diagram of a mashup sessionmanager managing a mashup session.

FIG. 1B depicts an example conceptual diagram of the mashup sessionmanager maintaining consistent views across different executionenvironments of the participants of the mashup session.

FIG. 2 depicts a flowchart of example operations for creating a mashupsession that can be shared across multiple execution environments.

FIG. 3 depicts a flowchart of example operations for updating mashupsession state information based on data generated by a mashupapplication and delivering the data to multiple participant executionenvironments.

FIG. 4 depicts a flowchart of example operations for adding services toan existing mashup application.

FIG. 5 depicts a flowchart of example operations for adding participantexecution environments to an existing mashup session.

FIG. 6 is an example conceptual diagram of a network for delivering datagenerated by mashup applications to participant execution environments.

FIG. 7 depicts a flowchart of example operations for dispatching anappropriate emergency responder using a distributed mashup.

FIG. 8 depicts an example computer system.

FIG. 9 depicts an example mashup session structure.

FIG. 10 depicts an example conceptual diagram of asynchronouscollaboration with a mashup session shared across different executionenvironments.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods,techniques, instruction sequences, and computer program products thatembody techniques of the present inventive subject matter. However, itis understood that the described embodiments may be practiced withoutthese specific details. For instance, although examples refer to WebServices Description Language (WDSL) and Representational State Transfer(REST) other feed techniques and service technologies can be used (e.g.,RSS, ATOM, etc.). In other instances, well-known instruction instances,protocols, structures, and techniques have not been shown in detail inorder not to obfuscate the description.

A mashup can be instantiated that runs across different executionenvironments and allows respective users of the different executionenvironments to collaboratively use and/or modify the mashup instance(“mashup session”). When any one of the multiple users submits aparameter to a view of the mashup session presented on their respectiveexecution environment, the views of the mashup session at all of theexecution environments can be updated in response, although individualconfigurations of the execution environments can lead to variances inthe views of the mashup session (e.g., colors, alerts, fonts, etc.). Amashup session manager maintains state of the mashup session to ensurepresentation consistency/uniformity across the execution environments.The mashup session manager also tracks the participating executionenvironments associated with a mashup session (e.g., usernames, deviceidentifiers, network addresses, etc.), and transmits data forpresentation consistency to the participating execution environments. Insome cases, a view of the mashup session at a participating executionenvironment may not be current (“stale mashup session view”). The mashupsession manager can detect if a view at a participating executionenvironment is of a past mashup session state, and provide data for thestale mashup session view to become current. In addition, the mashupsession manager can propagate design modifications to the participantsof the mashup session.

FIGS. 1A and 1B depict conceptual diagrams of consistent views of acurrent state of a mashup session across multiple executionenvironments. FIG. 1A depicts a conceptual diagram of a mashup sessionmanager managing a mashup session. FIG. 1A depicts a mashup sessionmanager 101 communication with devices 103, 105. The device 103 is acomputer, and the device 105 is a smart phone in FIG. 1A.

At stage A, the device 103 selects a mashup application from a mashupcatalog 109. The mashup catalog 109 can be stored locally or remotelywith respect to the device 103. For instance, the device 103 retrievedone or more files for the selected mashup in response to the selection.Selection of the mashup may involve any one of adding functionalityand/or data services to an existing mashup application, removingfunctionality and/or a data service from an existing mashup application,selecting multiple data services and assembling them into a mashup, etc.

At stage B, the device 103 indicates the selected mashup and one or moreparticipants to the mashup session manager 101. The device 103 canindicate the selected mashup in accordance with a variety of techniques.For example, the device 103 can communicate any one or more of a mashupidentifier, the mashup application itself, a database entry thatcorresponds to the mashup, etc. In addition, the device 103 can indicateparticipants for mashup session by device identifiers (MAC addresses, IPaddresses, device serial numbers, etc.), by usernames, by telephonenumbers, by e-mail addresses, etc. The device 103 may also selectparticipants with a user interface and/or participant data associatedwith or accessible by the mashup session manager 101.

At stage C, the mashup session manager 101 instantiates and populates amashup session structure 107 with indications of the mashup and theparticipants indicated by the device 103. The mashup session manager 101uses the mashup session structure 107 to maintain state of the mashupsession. Example data relevant to the state of the mashup sessionincludes actions performed, requests submitted to services of themashup, values of parameters submitted with requests, and resultsreceived in response to the actions performed. The mashup sessionmanager c101 can use the mashup session structure to update aparticipant device that may have a stale view of mashup session (e.g.,the participant device reconnects after losing connection, theparticipant device connects after the session begins, etc.).

FIG. 9 depicts an example mashup session structure. The depicted mashupsession structure can be a standalone structure or an entry or part ofanother structure (e.g., entry in a hash table, element of a tree,etc.). The example mashup session structure includes a mashup sessionidentifier field 901. The mashup session identifier field manager oneindicates a value that identifies a corresponding mashup session. Themashup session manager or some other process can generate the mashupsession identifier in accordance with a variety of techniques. Forexample, the mashup session manager can generate the mashup session anda log of a fire based upon a hash of an identifier of the owner andidentifier of the corresponding mashup application.

The mashup session identifier field identifier references a substructurethat includes a participants field 903, a mashup application identifierfield 905, and a state data field 907. The mashup application identifierfield 905 indicates a mashup application identifier. The state datafield 907 indicates at least a most recent result for the mashupsession. The state data field 907 can indicate a default of actions, alog of requests submitted to the services of the mashup, deltas ofresults, history of results, result history within a window of time,etc.

The participants field 903 references a substructure 909. Thesubstructure 909 (e.g., an array, list, a tree, etc.) identifies anorder of the mashup session and participants of the mashup session. Thesubstructure 909 also identifies devices associated with the owner andparticipants.

The mashup session manager 101 can also edit an entry of an existingstructure. For instance, a mashup session manager may be responsible forseveral ongoing mashup sessions, and manage them with one structure. Themashup session manager 101 could add an entry to this structure,overwrite an entry that already exists in this structure, etc. A mashupsession manager may maintain a mashup session structure for all ongoingmashup sessions managed by the mashup session manager, a mashup sessionstructure for each owner/creator, a mashup session structure for eachindividual session, etc.

After the mashup session structure 107 is instantiated and populated,the mashup session manager 101 communicates with the device 103 and thedevice 105. The communications can take place in any order and arerepresented by stages D1 and D2 in FIG. 1A. At stage D1, the mashupsession manager 101 establishes a connection with the participant device105 for the mashup session. The mashup session manager 101 indicates themashup session to the participant device 105. The mashup session manager101 establishes the connection with the device 105 using participantinformation previously indicated by the device 103 at stage B.Establishing the connection between the mashup session manager 101 andthe device 105 may involve setting up a channel, setting up acommunication session, authentication and verification operations,handshake operations, etc. Establishing the connection can also involvethe mashup session manager 101 querying the device 105 for executionenvironment for the connection (e.g., formatting information, encodinginformation, software version information, etc.). The mashup sessionmanager 101 may encapsulate, encode, and/or reformat data whencommunicating with the device 105. To indicate the mashup session to thedevice 105, the mashup session manager 101 can supply a reference ordata fire of the mashup session structure 107. The device 105 can accessthe mashup session structure 107 to retrieve the mashup application. Themashup session manager 101 can also or alternatively supply the mashupto the device 105 as well as an identifier or reference to the mashupsession structure 107. At stage D2, the mashup session manager 101indicates the mashup session to the session owner that corresponds tothe device 103. For example, the mashup session manager 101 transmitsdata that can comprise a memory address of the mashup session structure107, an identifier of the mashup session structure 107, an identifier ofthe mashup session structure 107 and an index into the mashup sessionstructure 107, etc.

At stage E, the device 103 performs an action in the mashup session andreceives a corresponding result from the Internet 109.

At stage F, the device 103 updates a view 106 of the mashup session withthe received result. FIG. 1A depicts the device 103 updating a mapmashup. The view 106 illustrates a map with three restaurant locationsand a public parking area nearest one of the restaurant locations thatis near an intersection. As an example, the device 103 may haveperformed an action in the mashup session to map restaurants that arenear the participants using the devices 103, 105 and that satisfycuisine criteria indicated profiles of the participants.

At stage G, the device 103 indicates the received result and theperformed action to the mashup session manager 101. For instance, device103 indicates a request generated from the mashup that corresponds tothe action performed at stage E to the mashup session manager 101 andthe responsive data. Embodiments do not necessarily communicateindications of both the received result and the performed action.Embodiments can communicate one of the received result and the performedaction to the mashup session manager 101.

At stage H, the mashup session manager 101 updates the mashup sessionstructure 107 with indications of the result and the action, thusreflecting state of the mashup session in the mashup session structure107. The mashup session manager 101 can maintain a history of actionsperformed during the mashup session in the mashup session structure 107.The history can be comprehensive or limited by a window of time. Themashup session manager 101 can indicate in the mashup session structure107 each result of each performed action, a most current result, a lastN results, a delta of a current result and a previous result, etc.

At stage I, the mashup session manager 101 indicates the result to theparticipant device 105. The mashup session manager 101 can also provideperformed action to the participant device 105. The participant device105 can automatically perform the performed action to obtain a currentview of the mashup session. The participant device 105 can compare theresults of device 105 receives from the Internet 109 against the resultindicated from the mashup session manager 101. Any differences can becommunicated back to the mashup session manager 101 for validationand/or propagation to other participants of the mashup session.

At stage J, the participant device 105 updates a view 111 of the mashupsession with the result indicated by the mashup session manager 101. Theviews 106, 111 of the mashup session at the respective devices 103, 105are consistent across the different execution environments of theparticipants.

FIG. 1B depicts an example conceptual diagram of the mashup sessionmanager maintaining consistent views across different executionenvironments of the participants of the mashup session. At stage A, theparticipant device 105 performs an action in the mashup session andreceives a corresponding result from the Internet 109. At stage B, theparticipant device 105 updates the view 111 of the mashup session withthe received result. In FIG. 1B, the participant device 105 has updatedthe view 111 to depict a volleyball field at the intersection of roads,and to no longer depict one of the previously depicted restaurants. Asan example, the participant device 105 may have performed an action inthe mashup session that requested indication of recreational facilitiesnear the restaurants already displayed, and an action in the mashupsession that added a cost criterion. The eliminated restaurant exceeded,or perhaps fell below, the cost criterion indicated by the participantdevice 105.

At stage C, the participant device 105 indicates the result in theaction to the mashup session manager 101.

At stage D, the mashup session manager 101 updates the mashup sessionstructure 107 in accordance with the action and the result indicated bythe participant device 105.

At stage E, the mashup session manager 101 indicates the result to theowner of the mashup session, which is the device 103. As stated earlier,the mashup session manager 101 can also indicate the result to thedevice 103.

At stage F, the device 103 updates the view 106 in accordance with theresult indicated by the mashup session manager 101. Alternatively, thedevice 103 can obtain the result from the Internet 109 by performing theaction indicated by the participant device 105. Although the exampledepicted by FIGS. 1A and 1B refer to obtaining results from theInternet, embodiments are not so limited. Embodiments can obtain resultsfrom any one or more of an intranet, virtual private network, and theInternet.

Although FIGS. 1A and 1B depict the mashup session manager 101 as beingseparate from the device 103 that initiated the mashup session,embodiments are not so limited. The mashup session manager 101 can beimplemented at an intermediate device (e.g., a cloud, server, etc.), onthe device 103, distribute across device 103 an intermediate device,etc. hence, communications that seemingly flow through the mashupsession manager 101 may be direct communications between the device 103,which initiated the mashup session, and devices of participants of themashup session. In addition, communications for the mashup session thatflow directly between participant devices can be mirrored to anintermediate device or entity (e.g., cloud that supports the mashupsession). Embodiments may also interject a mashup session managerbetween an initiating device and/or participant devices and theInternet. For example, actions performed at a participant device aresubmitted to the mashup session manager which generates thecorresponding requests and submits or causes to be submitted therequests to the appropriate data service. Embodiments can direct mashupactions and responses to the mashup actions through a mashup sessionmanager and/or processes spawned by or associated with the mashupsession manager. Embodiments can instantiate/supply user interfaces tothe participant devices that forward actions and corresponding parametervalues indicated with the user interfaces to the mashup session manager.The mashup session manager can then submit the actions and correspondingparameter values to the mashup application. The mashup session managercan broadcast or multicast results of the submitted actions to allparticipants of the mashup session. In addition, the mashup sessionmanger can perform operations to manage collisions among the executionenvironments. For example, embodiments can sequence and/or prioritizeactions, which impact state of the mashup session, performed at theexecution environments.

FIG. 2 depicts a flowchart of example operations for creating a mashupsession that can be shared across multiple execution environments. Arequest to create a mashup application is received (201) from anexecution environment. The request can indicate services to for themashup application according to a need contemplated by a designer of themashup application. The designer of the mashup application can beassociated with the execution environment.

Services for the mashup application are determined (203). Services canbe data sources, can provide functionality, or both. Examples of datasource type services include weather databases, business directories,and restaurant review aggregators. Examples of functionally typeservices include database managers, map applications, and trafficreporting applications. Functionality can be implemented in servlets,applets, applications, etc. The services can be provided by a mashupsession manager, a third-party, or a combination thereof. For example, amashup session manager can determine the services based on the request.As another example, the mashup session manager can determine theservices by querying the execution environment requesting creation ofthe mashup. The mashup session manager can provide an indication of theavailable services to the execution environment. The indication ofavailable services can include descriptions of the services that helpdesigners choose appropriate services for mashup applications thedesigners wish to create. In response, the execution environment candisplay the available services and can prompt the designer to selectservices for the mashup application.

The mashup application is created based on the services (204). Theservices can be wired together based on indications of the designer. Forexample, the purpose of the mashup application can be findingrestaurants convenient to the locations of several individuals. Theservices selected for the mashup are a restaurant database and a mapapplication. Both the restaurant database and the map application expectlocations as inputs. Locations can be represented by global positioningsystem (GPS) coordinates, addresses, intersections, etc. The designerindicates that restaurants should be retrieved from the restaurantdatabase based on locations that can be provided as inputs to the mashupapplication. Addresses of the restaurants output by the restaurantdatabase and the provided locations should be input into the mapapplication so that the map application can create a map of the providedlocations and the restaurants.

Participant execution environments associated with the mashupapplication are determined (205). For example, the mashup sessionmanager can determine the participant execution environments based onidentifiers indicated in the request. As another example, the mashupsession manager can determine the participant execution environments byquerying the designer's execution environment. The mashup sessionmanager can provide an indication of users known to the mashup sessionmanager. The users may be known to the mashup session manager becausethe users registered the users' execution environments with the mashupsession manager, the users' execution environments were previouslyassociated with a mashup application, etc. In response, the designer'execution environment can display the known users and can prompt thedesigner to select participants to associate with the mashupapplication. The designer can select participants from the known usersor can identify other users by providing contact information of theother users (e.g., an e-mail address, a phone number, an instantmessaging username, etc). The designer's execution environment isautomatically considered to be a participant execution environment.

A mashup session can be created based on the participant executionenvironments and the mashup application (207). Establishing the mashupsession can comprise generating a mashup session identifier andpopulating a mashup session state structure with data that associatesthe mashup application with the mashup session identifier and theparticipant execution environments. The mashup session structure can bepopulated with the mashup session identifier, an indication of themashup application, and indications of the participant executionenvironments. Examples of the indication of the mashup applicationinclude a name, a reference (e.g., a link to code, a memory address(i.e., pointer) to the code), code hash value, the mashup applicationitself, etc. Examples of indications of the participant executionenvironments include usernames, device identifiers (e.g., MAC addresses,phone numbers, etc.), network addresses, etc.

Data is retrieved from the mashup application based on parametersindicated by the participant execution environments (209). In theprevious example of the convenient restaurant locator mashup, a mashupsession manager determines the locations of each of the participantexecution environments. The mashup session manager can determine thelocations by querying the execution environments. The executionenvironments can automatically determine and return the parameters basedon stored data (e.g., a GPS coordinate of a mobile phone). The devicescan also prompt participants associated with the execution environmentsto enter the attributes. The mashup session manager can also determineparameters based on previously stored data accessible to the mashupsession manager. For example, parameters can be stored by the mashupsession manager when a user registers the users' execution environmentwith the mashup session manager. The mashup session manager can providelocations to the mashup as inputs. The mashup application can retrieve alist of restaurants from the restaurant database and utilize the mapapplication to generate a map of the restaurants and the locations ofthe participant execution environments.

State information associated with the mashup session can be updatedbased on the data (block 211). The data can be stored in the stateinformation associated with the mashup session identifier in the mashupsession structure. The request can be stored with the data in the stateinformation to maintain a history of requests and data generated by themashup application in response to the requests.

The data is delivered to the participant execution environments (213).The data can be delivered in accordance with state information to ensurepresentation consistency across the participant execution environments.Individual state information associated with each of the participantexecution environments with respect to the mashup application can bemaintained. The individual state information indicates a last state ofthe data that was viewed on a participant execution environment. Themashup session manager 101 can deliver data generated by the mashupapplication to the participant execution environment since the laststate. The data can be delivered to the participants by a REST webservice.

After a mashup session is established, requests made to a mashupapplication associated with the mashup session cause the mashupapplication to generate new data. FIG. 3 depicts a flowchart of exampleoperations for updating mashup session state information based on datagenerated by a mashup application and delivering the data to multipleparticipant execution environments. A request to a mashup application isreceived from a participant execution environment (301). For example, amashup session manager receives a request to add a new service to themashup application. As another example, the mashup session managerreceives a request to associate a new participant execution environmentwith the mashup application.

A mashup session associated with the participant execution environmentis determined (303). The mashup session can be determined based onlocating an identifier of the participant execution environment in amashup session structure and determining a mashup session identifierassociated with the participant execution environment identifier. Amashup application associated with the mashup session identifier canalso be determined.

Data is retrieved from the mashup application based on the request(305). For example, the request comprises an indication of a newexecution environment to participate in the mashup session. So, themashup session manager determines a location of the new executionenvironment and provides the location as an input along with locationsof other participant execution environments to a restaurant locatormashup application. The locations of other participant executionenvironments can be determined based on state data of a previous requestsubmitted to the mashup application. The mashup application retrieves anew set of restaurants from a restaurant database based on the locationsand utilizes a map application to create a new map of the locations andthe restaurants.

State information of the mashup is updated based on the data and therequest (307). State information can be stored in the mashup sessionstructure based on the mashup session identifier. The state informationcan maintain a history of requests and data generated by the mashupapplication in response to the requests.

Other participant execution environments associated with the mashupsession are determined (309). The other participant executionenvironments can be determined based on state information of the mashupsession.

Data is delivered to the participant execution environments inaccordance with the state information (311). Delivering the data to theparticipant execution environments can comprise determining that a stateof a first participant execution environment corresponds to a past stateof the mashup session and determining data generated by the mashupapplication since the past state of the mashup session based individualstate information corresponding to the first participant executionenvironment in the mashup session structure. The data generated by themashup application since the past state can be transmitted to the firstparticipant execution environment to update a view of the mashup sessionassociated with the first execution environment to the current state.For example, a Webpage representing the data is open in a browser of thefirst execution environment. A mashup session manager determines thatthe browser last loaded the Webpage prior to the latest request based onthe individual state information. The mashup session manager cantransmit an indication to the browser to cause the browser to refreshthe Webpage.

After a mashup application is created, any of the participantsassociated with the mashup can add services to the mashup. In responseto a mashup session manager adding the service to the mashupapplication, the mashup application can generate new data. The mashupsession manager can automatically update state information to reflectthe data and deliver the data to the participant execution environmentsassociated with the mashup application. FIG. 4 depicts a flowchart ofexample operations for adding services to an existing mashupapplication. A request to add a service is received from a participantexecution environment (401). For example, a mashup session managerreceives a request indicating a new service to be added to an existingmashup application.

A mashup session associated with the participant execution environmentsis determined (403). The mashup session manager can determine the mashupapplication based on state information for a mashup session associatedwith the participant execution environment.

Existing services of the mashup application are determined (block 405).For example, a mashup session manager determines the existing servicesof the mashup based on metadata of the mashup application.

The mashup application is updated based on indicated connections amongthe new service and existing services (407). For example, a user maywish to add a restaurant review aggregator to the convenient restaurantlocator mashup. The mashup session manager determines that a connectionshould be made between an output of the restaurant database to therestaurant review aggregator such that restaurant identifiers (e.g.,restaurant names, addresses, phone numbers, etc.) can be input into therestaurant review aggregator to retrieve reviews.

Data is retrieved from the mashup application based on parametersindicated by the participant execution environments (409). For example,a calendar application may be added to a mashup application forscheduling business lunches. A query containing the locations andcalendar identifiers of the participant execution environments can besubmitted to the business lunch scheduler mashup application. Inresponse, the mashup application can retrieve information about eachparticipant's free time from the calendar application based on anidentifier for each participant's calendar. In addition to retrievingdata from the additional service, the mashup can retrieve data from theexisting services if the attributes have changed. For example, a map ofthe restaurants may be updated if one or more of the participants'locations changed.

State information associated with the mashup session is updated based onthe data and the request (411).

Other participant execution environments associated with the mashup aredetermined (413). The participant execution environments can bedetermined based on state information of the mashup session.

Data is delivered to the participant execution environments inaccordance with the state information (415). For example, one of theparticipants opens a view of the data. Individual state information forthe participant can indicate that the participant last viewed the datawhen a previous request was submitted to the mashup application. Amashup session manager can determine data that was generated by themashup in response to the previous request and the current request anddeliver the data to the participant through the participant executionenvironments.

After a mashup session is created, new execution environments can alsobe selected to participate in the mashup session. For example, aparticipant wishes to invite more colleagues to a lunch meeting. FIG. 5depicts a flowchart of example operations for adding participantexecution environments to an existing mashup session. It is determinedthat an execution environment has been selected to participate in anexisting mashup session (501). For example, a mashup session managerreceives a request identifying the execution environment to be added asa participant in the existing mashup session. The participant executionenvironment can be identified based on contact information of a userassociated with the participant execution environment such as an e-mailaddress, a phone number, instant messaging username, etc. The requestcan include an identifier of the existing mashup session so the mashupsession manager adds the participant execution environment to theappropriate mashup session.

The existing mashup session is determined (403). For example, theexisting mashup session is determined based on an identifier in therequest.

Data generated by the mashup is determined based on the stateinformation (507). The execution device has never accessed a view of thedata, so a mashup session manager can determine data that was generatedby the mashup since the mashup was created.

The data is delivered to the execution environment (509).

FIG. 6 is an example conceptual diagram of a network for delivering datagenerated by mashup applications to participant execution environments.A mobile phone 605, a laptop computer 609, and a desktop computer 607are connected to a mashup session manager 601 through a network 603. Themobile phone 605, the laptop computer 609, and the desktop computer 607represent user devices registered with the mashup session manager 601.Although not shown, other user devices such as PDAs and portable musicplayers can be connected to the mashup session manager 601 through thenetwork 603.

The mashup session manager 601 is connected to various services 611through the network 603. The services can comprise data sources andfunctionality. In this example, the services 611 comprise a restaurantlocator 613, a weather service 615, a map application 617, and a trafficapplication 619. Other examples of services include businessdirectories, movie listings, calendar applications, etc. In thisexample, the services 611 are hosted on third-party servers (not shown).In other examples, some (or all) of the services 611 can be hosted onthe mashup session manager 601.

The mashup session manager 601 receives requests to create mashupapplications from the mobile phone 605, the laptop computer 609, and thedesktop computer 607, and creates the mashup applications based onselected services. The mashup session manager 601 associates participantexecution environments and a mashup application with a mashup session.The mashup session manager retrieves data from the mashup applicationbased on parameters indicated by the participant execution environments,updates state information of the mashup session to reflect the data, anddistributes the data the participant execution environments inaccordance with the state information. For example, the mashup sessionmanager 601 can receive a request for creating a mashup application forresponding to natural disasters from the desktop computer 607. Themashup session manager 601 can determine that the weather service 615,the map application 617, and the traffic application 619 constituteservices specified for the mashup. The mashup session manager 601 canalso determine that the laptop computer 609, the mobile phone 605, andthe desktop computer 607 have been selected as participant executiondevices associated with a mashup session. The mashup session manager 601can retrieve weather information from the weather service 615. When anatural disaster hits, the mashup session manager 601 can utilizeinformation reported by the weather service 615 to create a map, usingthe map application 617, of the natural disaster's location and imposethe locations of the participants on the map. The mashup session managercan integrate traffic information from the traffic application 619 withthe map to determine routes for each participant. The mashup sessionmanager 601 compiles the data generated by the mashup applicationcomprising the natural disaster information from the weather service615, the map and traffic information and updates state information ofthe mashup session based on the data and distributes the data to themobile phone 605, the laptop computer 609, and the desktop computer 607so that the participants associated with the mobile phone 605, thelaptop computer 609, and the desktop computer 607 can respond to thenatural disaster.

Although examples refer to a stand-alone mashup session manager,embodiments are not so limited. For example, functionality of the mashupsession manager can be implemented on a participant executionenvironment.

A distributed mashup can be created to dispatch appropriate emergencyresponse personnel to an emergency. Services such as a map application,a traffic application, and an emergency database, can be added to thedistributed mashup. Emergency responders can be selected participate inthe mashup based on identification of the emergency responders'execution environments (e.g., laptop computer in response vehicles,mobile phones, navigation units in the response vehicles, etc.). FIG. 7depicts a flowchart of example operations for dispatching an appropriateemergency responder using a distributed mashup. An emergency call isreceived (block 701). For example, an emergency is reported to a 911dispatch center. A 911 operator can input information about theemergency (e.g., location, type, etc.) into an emergency database.

A mashup session manager can detect that a new emergency has been addedto the emergency database and determine the location of the emergencyand type of emergency (block 703) based on information in the emergencydatabase.

Emergency responders to respond to the emergency are determined based onthe type (block 705). For example, firefighters should respond to a fireemergency. As another example, police officers and emergency medicaltechnicians should respond to a car accident.

Locations of the emergency responders are determined (block 707). Forexample, the mashup session manager queries the emergency responders'devices to determine GPS coordinates of the emergency responders.

A map application can be utilized to determine distances between thelocations of the emergency responders and the location of the emergency(block 709).

A traffic application can be utilized to estimate travel times for theemergency responders and determine best routes (711). For example,traffic information can be imposed on the map so that the mapapplication can determine the best routes.

An appropriate emergency responder is chosen based on the shortestdistances and travel times (block 713). Availability of the emergencyresponders can also be used to determine the appropriate emergencyresponder. For example, an emergency responder who has already beendispatched to a previous emergency is not chosen as the appropriateemergency responder.

The output of the mashup is stored (block 715). In this example, theoutput comprises the type and location of the emergency and the bestroute.

The output is sent to the appropriate emergency responder (block 771) todispatch the emergency responder. Although the output is sent to theappropriate emergency responder, the output can be distributed to otheremergency responders because the appropriate emergency responder mayneed backup or may not be able to respond due to external factors (e.g.,an increase in traffic along the best route).

Embodiments are not limited to the example flowcharts depicted in theabove figures. Embodiments can perform additional operations, feweroperations, operations in parallel, etc. For instance, referring to FIG.2, operations for creating a mashup based on the participant executionenvironments and retrieving data from the mashup application can beperformed in parallel. Referring to FIG. 5, the operations fordetermining existing services of the mashup application and determiningother participant execution environments can be performed in parallel.

As will be appreciated by one skilled in the art, aspects of the presentinventive subject matter may be embodied as a system, method or computerprogram product. Accordingly, aspects of the present inventive subjectmatter may take the form of an entirely hardware embodiment, an entirelysoftware embodiment (including firmware, resident software, micro-code,etc.) or an embodiment combining software and hardware aspects that mayall generally be referred to herein as a “circuit,” “module” or“system.” Furthermore, aspects of the present inventive subject mattermay take the form of a computer program product embodied in one or morecomputer readable medium(s) having computer readable program codeembodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain, or store a program for use by or in connection with aninstruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent inventive subject matter may be written in any combination ofone or more programming languages, including an object orientedprogramming language such as Java, Smalltalk, C++ or the like andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The program codemay execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through any type of network, includinga local area network (LAN) or a wide area network (WAN), or theconnection may be made to an external computer (for example, through theInternet using an Internet Service Provider).

Aspects of the present inventive subject matter are described withreference to flowchart illustrations and/or block diagrams of methods,apparatus (systems) and computer program products according toembodiments of the inventive subject matter. It will be understood thateach block of the flowchart illustrations and/or block diagrams, andcombinations of blocks in the flowchart illustrations and/or blockdiagrams, can be implemented by computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

FIG. 8 depicts an example computer system. The computer system can actas a mashup session manager. A computer system includes a processor unit801 (possibly including multiple processors, multiple cores, multiplenodes, and/or implementing multi-threading, etc.). The computer systemincludes memory 807. The memory 807 may be system memory (e.g., one ormore of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM,eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or anyone or more of the above already described possible realizations ofmachine-readable media. The computer system also includes a bus 803(e.g., PCI bus, ISA bus, PCI-Express bus, HyperTransport® bus,InfiniBand® bus, NuBus bus, etc.), a network interface 805 (e.g., an ATMinterface, an Ethernet interface, a Frame Relay interface, SONETinterface, wireless interface, etc.), and a storage device(s) 809 (e.g.,optical storage, magnetic storage, etc.). The computer system alsoincludes a mashup session manager 821. The mashup session manager 821can determine participant execution environments associated with amashup application and establish a mashup session based on the mashupapplication and the participant execution environments. The mashupsession manger 821 can also create a mashup session structure to mainstate of the mashup session and ensure consistent, current views of themashup session. The mashup session manager 821 can deliver datagenerated by the mashup application to the participant executionenvironments in accordance with the state information to ensurepresentation consistency across the participant execution environments.Any one of these functionalities may be partially (or entirely)implemented in hardware and/or on the processing unit 801. For example,the functionality may be implemented with an application specificintegrated circuit, in logic implemented in the processing unit 801, ina co-processor on a peripheral device or card, etc. Further,realizations may include fewer or additional components not illustratedin FIG. 8 (e.g., video cards, audio cards, additional networkinterfaces, peripheral devices, etc.). The processor unit 801, thestorage device(s) 809, and the network interface 805 are coupled to thebus 803. Although illustrated as being coupled to the bus 803, thememory 807 may be coupled to the processor unit 801.

As stated earlier, participants of a mashup session can modify themashup. Although a consistent view can be maintained across participantdevices, participants may choose to modify the mashup for their ownpurposes without synchronizing the changes to the other participantdevices. Hence, the various participants can asynchronously interactwith the mashup in the mashup session. Although the interactions wouldbe asynchronous and the views vary, the mashup session manager maintainsa global perspective of the mashup session. Thus, participants canasynchronously collaborate with the mashup, and be aware of otherparticipant's interactions with the mashup without necessarily beingconfined to a uniform, global view of the mashup session.

FIG. 10 depicts an example conceptual diagram of asynchronouscollaboration with a mashup session shared across different executionenvironments. FIG. 10 illustrates a computer 1001, a smartphone 1005,and a mashup session manager 1003. For this illustration, the mashupsession manager resides on an intermediate device, for example on aserver.

The computer 1001 creates a mashup application 1007. As depicted in FIG.10, creation of the mashup application can involve selecting from acatalog of mashup applications, and possibly modifying a selected mashupapplication. The mashup application 1007 can also be created with a toolthat generates code based on services and functionality selected by auser. In FIG. 10, the computer 1001 creates the mashup 1007 to use aservice A and a service B. The created mashup is indicated to the mashupsession manager 1003, where mashup code 1009 is created. Embodiments cancreate the mashup code at the mashup session manager 1001 with data sentfrom the creating computer 1001 that indicates the services andfunctionality. Embodiments can also send the mashup code 1007 to themashup session manager 1003. Embodiments can also create the mashup 1007at the mashup session manager 1003, instead of at the computer 1001. Forinstance, the indications of services and functionality can be performedwith a user interface at the computer 1001, while the generation of themashup application code is done at the mashup session manager inresponse to the indications with the user interface. Embodiments canalso generate different degrees of the mashup application code in thedifference environments. For example, the mashup session manager candistribute mashup application code that comprises Perl script, DHTMLcode, and XSQL code. In another example, the mashup session manager candistribute mashup application code that indicates services (e.g., links,names of the data services, etc.), and how the services are wiredtogether or how the services should be wired together. The executionenvironments can add additional code for presentation functionality(e.g., user interface components), additional code that operates upondata from the services, additional code that filters results from theservices, additional code that manipulates input to be submitted to theservices, additional code that implements the wiring, etc.

As discussed earlier, creating the mashup session involves addingparticipants. In accordance with information provided by the computer1001, the mashup session manager 1003 establishes a connection with thesmartphone 1005. Adding the smartphone 1005 as a participant device cancomprise any one of sending the mashup code 1009 to the smartphone 1005,communicating a reference (e.g., network location) of the mashup code1009 to the smartphone 1005, creating a connection for the computer 1001to communicate the mashup code 1007 to the smartphone 1005, etc. Afterobtaining sufficient information, the mashup session manager 1003instantiates the mashup session based upon the mashup code 1009.

After joining the mashup session, the smartphone 1005 modifies themashup code 1009. The smartphone 1005 removes service B, and adds aservice C and a service D, resulting in a mashup code 1011. Thesmartphone 1005 communicates the modification to the mashup sessionmanager 1003. The mashup session manager 1003 updates the mashup sessiondata accordingly. For instance, the mashup session manager caninstantiate a mashup session structure or modify a data structure entryfor the participant device 1005 that indicates the mashup code 1011, orat least the modifications. In FIG. 10, the mashup session manager 1003modifies the mashup code 1009 to use services C, D, which were added bythe smartphone 1005.

The mashup session manager 1003 then notifies the computer 1001 of themodifications made at the smartphone 1005. Although the computer's viewcan be synchronized with the view of the mashup session at thesmartphone 1005, the computer 1001 opts to receive notifications ofresults and/or interactions of other participants (or a particularparticipant) instead of synchronizing the view of the mashup session. Toillustrate, a first user creates a mashup to map restaurant locationswithin a threshold distance of all participants. So, the mashup utilizesa map service, a restaurant listing service, and global positioningservices of the participants' devices. One of the participants may notcare about the cuisine, but wants to find a ticket vendor near allparticipants. This participant modifies the mashup at his/her device touse a map service, the GPS services, and a ticket vendor directory. Athird participant may not want to view the map, perhaps to conservepower, and only wishes to see reviews of restaurants returned to thequery of the first participant. The mashup session manager can maintaindata and code that provides results, or is aware of the results, thatmap restaurants for the first participant, and that map ticket vendorsfor the second participant. The mashup session manager can receiveinteract with the device of the third participant to retrieve restaurantreviews for the third participant for only those restaurants in theresult provided to the first participant.

Although FIG. 10 depicts the mashup session manager modifying the mashup1009 to reflect additions made by the participant device 1005,embodiments are not so limited. Embodiments can maintain each differentmashup code for the different participant devices. For example,participant A uses services A and B; participant B uses services A, B,and C; and participants C and D use services A, B, and E. The mashupsession manager can maintain separate mashup code for participants A, B,and a single mashup code for participants C and D. In addition to theseparate mashup codes, the mashup session manager can also maintain aunifying mashup code that utilizes all of the services. The mashupsession manager maintains data and code that allows views of the mashupsession to be consistent across participant devices, if desired. And themashup session manager can notify a first participants of resultsreceived/used by a second participant, without homogenizing the views ofthe mashup session. Embodiments can also allow a participant device topresent at least a few if not all of the different views of the mashupsession. Using the above illustration, a first participant device candisplay a first map of restaurants, a second map of ticket vendors, anda listing of the restaurant reviews of the mapped restaurants. Thus, theshared mashup session is flexible enough to allow collaboration ofparticipants across devices in a mashup session with or withoutsynchronization of views.

Furthermore, embodiments are not limited to services provided fromwebsites on the Internet. As discussed above, a mashup can utilize aservice of participant devices, such as the global positioning dataprovided by each device. Mashups can utilize services provided at theserver hosting the mashup session manager, services provided by anintranet, etc.

While the embodiments are described with reference to variousimplementations and exploitations, it will be understood that theseembodiments are illustrative and that the scope of the inventive subjectmatter is not limited to them. In general, techniques for distributingmashups across execution environments as described herein may beimplemented with facilities consistent with any hardware system orhardware systems. Many variations, modifications, additions, andimprovements are possible.

Plural instances may be provided for components, operations, orstructures described herein as a single instance. Finally, boundariesbetween various components, operations and data stores are somewhatarbitrary, and particular operations are illustrated in the context ofspecific illustrative configurations. Other allocations of functionalityare envisioned and may fall within the scope of the inventive subjectmatter. In general, structures and functionality presented as separatecomponents in the exemplary configurations may be implemented as acombined structure or component. Similarly, structures and functionalitypresented as a single component may be implemented as separatecomponents. These and other variations, modifications, additions, andimprovements may fall within the scope of the inventive subject matter.

What is claimed is:
 1. A method comprising: generating a mashup sessionidentifier for a mashup session based, at least in part on a mashup thatuses a first set of services to generate results in response to requestssubmitted to the mashup; associating a plurality of participant deviceswith the mashup session identifier; establishing connections with theplurality of participant devices; determining that a first of theplurality of participant devices modifies the mashup either to add aservice for the mashup to use in conjunction with the first set ofservices for generating results in response to requests submitted to themodified mashup or to remove one of the first set of services; andmaintaining state data for the mashup session that represent at least afirst current result generated by the mashup from use of the first setof services and that represent at least a second current resultgenerated by the mashup as modified.
 2. The method of claim 1 furthercomprising at least one of synchronizing views of the mashup sessionacross the plurality of devices to indicate the first current result andthe second current result, notifying the first participant device of theat least first current result, presenting separate views of the mashupsession that reflect the first current result and the second currentresult at a second participant device.
 3. An apparatus for presenting amulti-user mashup session across execution environments, the apparatuscomprising: a processor; and a computer readable storage medium havingcomputer readable program code executable by the processor to cause theapparatus to, generate a mashup session identifier for a mashup sessionbased, at least in part on a mashup that uses a first set of services togenerate results in response to requests submitted to the mashup;associate a plurality of participant devices with the mashup sessionidentifier; establish connections with the plurality of participantdevices; determine that a first of the plurality of participant devicesmodifies the mashup either to add a service for the mashup to use inconjunction with the first set of services for generating results inresponse to requests submitted to the modified mashup or to remove oneof the first set of services; and maintain state data for the mashupsession that represent at least a first current result generated by themashup from use of the first set of services and that represent at leasta second current result generated by the mashup as modified.
 4. Theapparatus of claim 3, wherein the computer readable storage mediumfurther comprises computer usable program code executable by theprocessor to cause the apparatus to, at least one of, synchronize viewsof the mashup session across the plurality of devices to indicate thefirst current result and the second current result, notify the firstparticipant device of the at least first current result, presentseparate views of the mashup session that reflect the first currentresult and the second current result at a second participant device.